Modern computer programs are typically created using modular programming approaches in which the various functions of a computer program are divided into interdependent modules. Each module is a component of a program that performs a specific set of related behaviors. Examples of such modular programming approaches include object oriented programming (e.g., Java, C++, etc.), where programs are structured as collections of interrelated objects, and functional programming (e.g., Mathematica, Extensible Stylesheet Language Transformations (XSLT), etc.), where programs are structured as collections of mathematical functions.
Modular programming approaches are adept at modularizing design features that can be cleanly divided. However, design features that cannot be cleanly divided (e.g., where the same or similar functionality affects multiple different concerns) cannot typically be modularized. These design features are said to be crosscutting concerns, and occur when a concern depends on and/or must affect parts of the implementation of several distinct modules. A concern is a set of behaviors needed to perform a specific feature of a computer program, which has been implemented in a code structure. Concerns can be divided into core concerns and crosscutting concerns. A core concern is a concern that performs operations that relate to the main domain, or responsibility, of a module. These operations may be referred to as core operations. Core concerns are often referred to as business concerns. A crosscutting concern is a concern that spans multiple modules (e.g., that cannot be completely separated from other concerns). A crosscutting concern typically affects multiple core concerns. Examples of crosscutting concerns include security, data logging, session management, authentication, etc.
Implementing crosscutting concerns in traditional programming languages typically requires the same or similar bits of code throughout the program, resulting in code that is tangled and/or scattered. For example, by its nature a security concern cuts across, and must be uniformly applied to, many of the natural units of modularity of a computer program. Because the security concern cuts across multiple modules, it isn't reusable, can't be refined or inherited, and is spread throughout the program in an undisciplined manner.
Aspect oriented programming (AOP) is a programming approach that was developed to address the limited manageability of crosscutting concerns in conventional programming approaches. An aspect includes a concern that crosscuts the primary modularization of a program. An aspect oriented programming language encapsulates crosscutting concerns in a number of special purpose program modules called aspects, rather than spreading the implementation of such concerns throughout the modules that include core concerns of a program. An aspect is the unit of modularity for crosscutting concerns, and includes a pointcut and advice. A pointcut is program code that picks out certain join points (a clearly definable point in a program flow, examples of which include method calls, exception throws, etc.) and values at those points. Advice is code (e.g., one or more operations) that can be executed when a join point is reached. Advice can define crosscutting functionality that transparently forces a modification to a core concern or adds additional functionality to a core concern. Advice is divided into before advice and after advice. Before advice is advice that runs as a join point is reached, before the program proceeds with the join point. After advice is advice that runs after the program proceeds with the join point.
Aspects can be applied to modules in well defined ways. For example, an aspect applied to a program constructed using an object oriented approach can affect the implementation of several classes (or several methods within a single class) in a clean, principled manner.
In conventional aspect oriented approaches, aspect code must be collocated with standard (non-aspect) code on a computer system. Therefore, if multiple networked computing systems implement the same aspect, they must each include a separate local instance of the same aspect code. Current aspect oriented programming languages also require that the aspect code and the standard code be compiled together. If the aspect code is not compiled together with the standard code, the aspects cannot typically be applied to core concerns of a compiled program. This can slow down the development and/or implementation of computer programs.